VB.NET versus C#
Hi Folks!!
many of our frndz wanna noe ab't this question, so i would like to answer this questions
Q: any advantages C# would have over Visual Basic (VB) in terms of the framework?
Answer: Regarding C# vs. Visual Basic, it really primarily comes down to what you already know and are comfortable with. It used to be that there was a large perf difference between VB and C++, but since C# and VB.NET use the same execution engine, you really should expect the same perf. C# may have a few more "power" features (such as unsafe code), and VB.NET may be skewed a bit more towards ease of use (e.g. late bound methods calls), but the differences are very small compared to what they were in the past.
Q: Okay, can we contrast C# with VB.NET? Questions usually come in the form of "I know you guys say VB.NET and C# let you do the same thing, but C# was designed for the CLR, so I don't believe you when you say VB.NET is just as good."
Answer: Regarding C# versus VB.NET, the reality is that programmers typically have experience with either C++ or VB, and that makes either C# or VB.NET a natural choice for them. The already existing experience of a programmer far outweighs the small differences between the two languages.
Q: Could you discuss the security of the config files. I have seen a lot of concern that since they are simple XML files, they can be hacked into easily.
Answer: We do block all access to the config files from remote users. However, I think the concern people have is whether a rogue user who gets access to the config file can modify and take over things. Note that this problem exists with ASP today as well, in that the metabase APIs can be written to, which would effectively do the same thing. However, there are some things that you can do to reduce this problem. Specifically, with ASP.NET we support the ability to "lock down" settings at a parent directory. For example, you might want to lock down the security identity of the worker process (i.e.: the username it runs under) at the machine level and then restrict sub-applications' abilities to override it.
Q: I've seen a lot of concern that data can be passed page to page (ASP to and from ASP.NET).
Answer: Since we really use standard Web techniques, passing info page to page should not be a problem. However, page to page in ASP and ASP.NET typically assumes services that are provided by each, such as session and application state. These services are not shared, and so you can't rely on them. I have a list of things you can do to ease migration of ASP code to ASP.NET.
1. Use only a single language within the ASP application. Don't intermix VBScript and JScript together in the same page (in general a bad programming practice with ASP, but also a migration issue for ASP.NET in that we now require only one inline <% %> language.
2. Explicitly declare all of ASP page functions within a